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Runtime verification is checking whether a system execution satisfies or violates a given correctness 
property. A procedure that automatically, and typically on the fly, verifies conformance of the sys- 
tem's behavior to the specified property is called a monitor. Nowadays, a variety of formalisms are 
used to express properties on observed behavior of computer systems, and a lot of methods have 
been proposed to construct monitors. However, it is a frequent situation when advanced formalisms 
and methods are not needed, because an executable model of the system is available. The original 
purpose and structure of the model are out of importance; rather what is required is that the system 
and its model have similar sets of interfaces. In this case, monitoring is carried out as follows. Two 
"black boxes", the system and its reference model, are executed in parallel and stimulated with the 
same input sequences; the monitor dynamically captures their output traces and tries to match them. 
The main problem is that a model is usually more abstract than the real system, both in terms of func- 
tionality and timing. Therefore, trace-to-trace matching is not straightforward and allows the system 
to produce events in different order or even miss some of them. The paper studies on-the-fly confor- 
mance relations for timed systems (i.e., systems whose inputs and outputs are distributed along the 
time axis). It also suggests a practice-oriented methodology for creating and configuring monitors 
for timed systems based on executable models. The methodology has been successfully applied to a 
number of industrial projects of simulation-based hardware verification. 

1 Introduction 

Verification has long been recognized as one of the integral parts of software and hardware design pro- 
cesses |[T5l l22l . Generally, it is an activity intended to check whether a system or its part meets a 
specification (set of functional and timing requirements). Verification techniques can be divided into 
two main groups, namely formal verification and testing (also known as simulation-based verification 
in the hardware engineering domain) lTT4l . Formal methods are aimed at rigorous proving or disproving 
the correctness of a formal model of a system with respect to a formal specification. Such approaches 
exhaustively examine all possible executions of a given system - either explicitly (by enumerating all 
reachable states) or implicitly (by using symbolic techniques). In contrast, testing deals with a finite 
number of executions and estimates the system's behavior in a finite number of situations (so-called 
test situations). Runtime verification is a common point of both. Like testing, it works with concrete 
executions of a system, but does it in a formal way. 

In runtime verification, a correctness property is typically expressed in a formal language, which 
makes it possible to automatically translate the property into a monitor. Such a monitor is then used to 
check a system execution with respect to that property Q. The idea is similar to specification-based 
testing, where a formal specification serves as a basis for generating a test oracle, which, like monitor, 
determines whether an observed behavior is consistent with the specification ifTTlfL?! . But, as opposed 
to testing, it is not a scope of runtime verification to construct test sequences and apply them to the 
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system under test. The task is to passively observe inputs and outputs of the system and to check their 
conformance - that is why it is also called passive testing 0. Formally, when £(<p) denotes the set 
of valid system executions given by property <p, runtime verification is aimed at checking whether a 
concrete execution w is an element of £(<p). In this sense, runtime verification deals with the word 
problem, i.e., identifying whether a given word is included in some language [5]. 

Correctness properties in runtime verification may be expressed using a variety of different for- 
malisms, including extended regular expressions [21], contract specifications 111 211 and rule-based ap- 
proaches El. Temporal logic, which is well-known from model checking [10], is also very popular in 
runtime verification, especially variants of linear temporal logic, such as LTL and TLTL (a natural coun- 
terpart of LTL in the timed setting) 0. There are also a lot of methods for generating effective monitors 
(or test oracles) from formal specifications. However, sophisticated formalisms and methods are not 
always suitable for industrial practice. For example, many hardware design companies use executable 
software models for design space exploration and architecture modeling; it is quite natural to reuse those 
models for verification and monitoring. High reusability within a project is important to complete ver- 
ification within the timeline [19]. Moreover, reusable models ensure conceptual integrity of the project 
and accelerate the knowledge interchange. 

Runtime verification based on executable models is carried out in the following way. A reference 
model is co-executed with the target system and applied with the same inputs as the system under verifi- 
cation. The outputs of two "black boxes" are given to the monitor that matches them and decides whether 
they are consistent. Aside from minor technical difficulties on organizing co-execution and transforming 
interfaces, there is a conceptual problem relating to model abstractness. As a rule, a model (tending to be 
as simple as possible) does not specify the system's behavior accurately, which makes the output match- 
ing awkward. If the model produces some outputs in some order, it does not necessarily mean that the 
system should do it in the same manner - the order may differ and some of the ouputs may be omitted. 
Before using a model for monitoring one has to specify a priori information on its abstractness and give 
it to the monitor. One of the contributions of this paper is an approach that allows easy adaptation of 
monitors for models represented in different abstraction levels. 

We consider timed systems, which react on inputs distributed in time and emit outputs at dedicated 
time points. Formally, it means that each event is paired together with a time stamp, identifying when 
exactly the event happened. For the discrete-time model, timed sequences of events can be easily trans- 
formed into ordinary ones by removing time stamps and inserting a special tick event in proper positions 
of the original sequence (as many times as necessary) Q. Nevertheless, even in that case, it is con- 
venient to suppose that each event is tagged with a time stamp. Executions of a system and its model 
are described by timed sequences over the same alphabet. Assumptions on the model abstractness allow 
dynamical generalization of linear sequences into the partially ordered multisets consisting of events 
and time intervals associated with them. In general terms, the monitor checks on the fly that an im- 
plementation trace is a linearization of the generalized specification trace (subset of the trace) and all 
implementation events satisfy the corresponding time interval constraints. 

The rest of the paper is organized as follows. Section 2 introduces the basic mathematical notions 
used in the work such as a timed word, trace and pomset. Section 3 is the main part of the paper, in which 
the suggested method for timed trace matching is described. The section formalizes implementation and 
specification behavior and defines a conformance relation between implementations and specifications. 
It also describes a monitoring approach in detail and states its correctness. Section 4 outlines our expe- 
rience in using the proposed approach for simulation-based verification of industrial hardware designs. 
Section 5 is a brief survey of the related work. Section 6 concludes the paper and discusses some of our 
future research directions. 
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2 Preliminaries 

For the rest of the paper, £ denotes a finite alphabet of events, while T denotes a time domain. An 
event might be considered as a set of propositions that identify a situation when the event happens. A 
time domain is a totally ordered set with no upper bound, typically, N (discrete-time model) or M-° 
(continuous-time model). Sequences of events are called words (the empty word is denoted by e). Sym- 
bols £* and £ ffl stand for the sets of finite and infinite words over £, respectively. The length of a word w 
is denoted by \w\. If u and v are two words over the same alphabet and u is finite, then uv denotes their 
concatenation. For w = uv we say that w is a continuation of u with v. 

Sometimes, it is useful to structurize events by dividing them into inputs and outputs (£ = I DO) and 
by introducing a notion of port ifTTl . Let P = {1,2, and port : £ — >• P. Then, the tuple (£i , ...,£&), 
where £ p = port -1 (/?), is called a distributed alphabet. 

Definition 1 (Timed word - Alur and Dill |2|) A f/raeci wort/ w over the alphabet £ arac/ the time do- 
main T is a sequence (ao,to)(ai,ti)... of timed events (a;,/,) GlxT, satisfying the following constraints: 

1. for each i > 0, ?, < /zo/tfa (monotonicity); 

2. if the sequence is infinite, for every t € T ?/zere is some i > 0, such that tj > £ (progress). □ 

Strict monotonicity in the definition above can be weaken to monotonicity (i.e., it can be required that 
U < for all i > 0) O. (£ X T)* and (E x T) ffl denote the sets of finite and infinite timed words, 
respectively. Note that port partitioning implies an additional constraint on a timed word: 

3. for all i,j > 0, such that i ^ j and f; = tj, port(e;) ^ port(e/) (sequentiality). 

In concurrent systems, the concept of independence is often in use. Two events are considered as 
independent if they cannot be causally related (i.e., they may happen concurrently). Events on different 
ports are usually independent, while those on the same port are dependent. Concurrent execution can 
be modeled by partially ordered traces of events, where incomparable events are supposed to occur in 
indeterminate order or in parallel |6l. This intuition underlies two formal models of non-interleaving 
concurrency: (1) Mazurkiewicz's trace model |[T8l and (2) Pratt's pomset model l20ll . The definitions 
and their extensions for the timed case are given below. 

Definition 2 (Trace - Mazurkiewicz [ 18 1) An independence relation over the alphabet £ is a symmet- 
ric and irreflexive relation J C £ x £ Given an independence relation 3, a pair (£, 3) is called a concur- 
rent alphabet. Two words u and v are called Mazurkiewicz equivalent (u =j v) iff u can be transformed 
to v by a finite number of exchanges of adjacent, independent events. A Mazurkiewicz trace (or, simply, 
a trace) is an equivalence class of words by the Mazurkiewicz equivalence relation. □ 

The set of traces over the concurrent alphabet (£, J) is denoted as M(£, 3). Given an independence 
relation 3, the relation 3D = (£ x £) \ 3 is called the dependence relation. The length of a trace T (denoted 
by |t|) is the length of any of its representatives. If w is a word, [w]j is the trace that includes w as 
a representative. A concatenation of traces over the same concurrent alphabet (£, 3} is defined by the 
equality [m]j[v]j = [uv]j. A trace a is called a prefix of z (a C t) iff there exists y, such that ay = T. 

Example 1 (Traces) Let £ = {a,b,c,d} and 3 = {(a,b) , (b,a) , (c ,d) , (d,c)}. Then, some traces are as 
follows: 

[eh = {e} 
[ad]j = {ad} 
[ab]j = {ab,ba} 
[abcd]j = {abed, bacd,abdc, bade} 
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Figure 1 : Sequential and parallel composition of simple pomsets 



Definition 3 (Pomset (partially ordered multiset) - Pratt [20]) A L-labeled partial order is a tuple 
{V,^,X), where V is a finite set of vertices and X : V — > E is the labeling function. Two ^-labeled 
partial orders are called equivalent iff they are order- and label-isomorphic ( i.e., they are either equal or 
differ only in the names of vertices). A pomset over the alphabet E is an isomorphism class of L-labeled 
partial orders. □ 

Note that words are equivalent to pomsets with the total order, while multisets are equivalent to 
pomsets whose partial order is the equality. For convenience, we will use a concrete representative (a 
labeled partial order) to denote the pomset. There is a number of operations on pomsets, including 
parallel and sequential composition. Let a = (V,^,X) and y = (V, , X'} are pomsets over the same 
alphabet, such that V n V = 0. Define the pomsets (a || y) and (a ; y) as follows: 

(a||y) = (VUV',^U^',XuX') 

(a;y) = (VUV',^U ■<' U(V x V'),XuX') 

Example 2 (Pomsets) Examples of pomsets in the form ofHasse diagrams (i.e., drawings of the partial 
order transitive reduction), may be found in Figure^ 

A linearization of a pomset {V,<,X) is a total labelled order (V,<,X), where ^C<. The set of 
linearizations of a pomset a is denoted by lin(a). A designation x_l_y means that neither x < y nor y < x. 
We say that x G V immediately precedes y G V and write x-ky iff x -< y and there is no such z G V that 
x -< z -< y. A history of x G V is the set I x = {y G V \ y X x} (for X C V, I X = \J xeX I x). 

It can be shown that each trace can be represented as a pomset. The opposite is true only for a 
restricted class of pomsets O. Let (E, J) be a concurrent alphabet and a = (V, -<, X) be a pomset, such 
that 

- for each x G V, | x is a finite set; 

- for allx,y G V, if x_Ly, then (X(x),X(y)) G J; 

- for allx,y G V, iix^y, then (X(x),X(y)) G D. 

Then, lin(a) is a trace over (E, J) and a = pom(lin(a)) [6j. Further, we will represent traces as pomsets 
satisfying the conditions above. The same consideration is done in lTT6l [8l. 

Definition 4 (Timed trace - Chieu and Hung |8l) A timed trace over the concurrent alphabet (E, J) 
and the time doman T is a quadruple (V,^,X,6), where (V,^,X) is a trace over (E, J) and G : V — > T 
is a time function satisfying the following conditions: 
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Figure 2: Scheme for checking conformance between implementation and specification 

1. forallx,y G V, ifx -<y, then 9(x) < 9(y) (causality); 

2. if the trace is infinite, then for every f £ T there is a cut C C V, such that min AG c{0(x)} > t 
(progress). □ 

The set of timed traces over the concurrent alphabet (E,J) and the time domain T is denoted as 
Me(L, J,T). Note that timed words are a particular case of timed traces. Given a non-empty timed trace 
a = (V,^,X,6), begin(a) = m\n xe v{6(x)} and end(a) = max xe v{Q(x)} (if o is infinite, end(a) = °°); 
G[t,t+At] i s a sub-trace of a consisting of x <EV, such that 6(x) G [f,f + At]. Let TJ(T) be the set of time 
intervals over the time domain T (i.e., TJ(T) = {[/,/+ At] \ t,t+At G T}). 

Definition 5 (Time interval trace) A time interval trace over the concurrent alphabet (£, 3) and the 

time doman T is a quadruple a = (V, ^,X,8), where {V, ^, X) is a trace over (L, J) and 8 : V — > 73 '(T) 
w a function that associates a time interval to a vertex. The language of the time interval trace o is the 
set L(a) = {(V,^,X,d) eM e {L,3,T) | Vx G V . d(x) G 5(x)}. □ 

The set of time interval traces over the concurrent alphabet (E, 3) and the time domain T is denoted 
as Mg(£, 3,T). Futher we will deal with pairs consisting of a timed trace a and a time interval trace a§, 
such that a G £(<J§). Such a pair can be expressed as a quintuple (V,^,X,6 ,8} and is referred to as an 
extended time interval trace. The set of such traces is denoted as M e g(E, J,T). 

3 Runtime Verification with Executable Models 

A timed word (more precisely, a timed trace with an empty partial order) describes a concrete execution 
of the implementation under verification, while an extended time interval trace being more general can 
be considered as a specification behavior. Our goal is to check whether an implementation timed word 
w\ G (E x T)*( ffl ) is conforming to a specification trace Cs G Mg^Z, 3,T). Note that we are interested in 
on-the-fly checking, which means that a monitor "lives" in time and matches two traces in an event-driven 
fashion. Trace acceptance (verdict) at a given time point has a three-valued semantics J5j: (1) false (an 
inconsistency has been detected), (2) true (the implementation execution has been completed and its 
trace is conforming to the specification trace) and (3) inconclusive (the monitoring is in progress and no 
inconsistency has been found). 

To make it clear where a specification trace comes from, an additional explanation should be pro- 
vided. As it was said in the introduction, a system specification is represented in the executable form. 
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Hence, it can be executed and its executions (as ones of the implementation) are represented as timed 
words. The straightforward testing of the equality of two timed words is often inadequate and makes 
sense only for time-accurate specifications. Specifications are usually more abstract than implementa- 
tions, especially in terms of event ordering and timing. Assumptions on the specification abstractness 
generalize a concrete timed word to the extended time interval trace softening the conformance checking. 
Formally, abstraction is a map A : (E X T)*( ffl ' -> M e5 (E, J,T), such that w is conforming to A(w) for 
every w G (E x T)*( a \ A specification timed word ws is mapped into the extended time interval trace 
■A(ws) = Os- Then, it is checked whether an implementation word wi is conforming to the constructed 
specification trace Os- This scheme is illustrated in Figure[2j Technical details can be found in Section 4. 

3.1 Conformance Relation 

The next definition formalizes system executions in terms of timed traces. It also singles out input and 
output sequences as particular cases of traces corresponding to stimuli to a system and its reactions, 
respectively. System behavior is then abstractly defined as a map of inputs to outputs. 

Definition 6 (Execution trace) An execution trace over the concurrent alphabet (E, J) and the time do- 
main T is a timed trace with the empty partial order (i.e., a trace of the kind (V, 0, X, 6)). ifE = /UO, 
then execution traces over the alphabet I are called input sequences, while execution traces over the 
alphabet O are referred to as output sequences. □ 

Note that the empty partial order in execution traces reflects a fact that an implementation is a "black 
box", and, therefore, the cause-effect relation between its events is unknown. The sets of input and output 
sequences are designated by Ie(£,T) and Oe(E,T), respectively. Hereinafter, we will use the shortened 
notations: I = I e (E,T) and O = O (E,T). 

Definition 7 (Behavior) Deterministic timed behavior ( or, simply, behavior) over the alphabet £ and 
the time domain T is a (partial) map H : I x T — > O satisfying the following constraints: 

- for every w G I andt G T, end('B(H',f)) < t holds (future uncertainty); 

- for every w G I andt G T, ¥>(w,t) = 23(wr 0if ],?) holds (time directivity); 

- for every w G I and every f£T, there exists wv G I, a continuation of w, and At > 0, such that 
end('B(wv,t + At)) >t (liveness). □ 

The idea behind the concept is clear. Behavior describes how an input sequence is transformed into 
the output sequence taking into account an observation time point. Usually, when an input sequence is 
applied, then after a finite number of time units (counting from the last input time) the output sequence 
is fully observed and is ready to be checked. Such post-mortem analysis is not however what we are 
interested in. There are two reasons for that: (1) to ease the analysis, an execution should be terminated 
as soon as a failure is detected; (2) storing long sequences in memory is costly. Providing that a reference 
model is available, consider how it can be used for checking implementation behavior in runtime. Let 
us extend the definition above by allowing a specification to return extended time interval traces over the 
outputs (not concrete sequences as it is required). Denote the set of such traces as Ogg. 

Given an output trace (V,^,X,8,8) G Ogg, define two functions, Af ± , such that for every x G V, 
8(x) = [8(x) —At~(x),d(x) -\-At + (x)]. Assume that functions Af* are bounded (i.e., there exist constants 
AT* > 0, such that IA^jc)! < AT^ for all x G V). Assume also that values At ± (x) depend only on 
the event not on the vertex itself (i.e., At ± (x) = At ± (X(x))). Let 3 and § be an implementation and 
specification behavior, respectively. Given an input sequence w G I, a time point t G T, let us consider 
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Figure 3: Conformance between implementation and specification 

implementation and specification outputs: J(w,t) = (Vj , , /tj , dj) and §(w,t) = (Vg,^§,X§, 6§,d§). Let 
us introduce the following notations: 

pastf(w,/) = {y e 3{w,t) \ fy(y) < (t - At~ (y))}; 

pastj(w,/) = {y G %,/) | fy(y) < t}\ 

pastf(w,/) = {xe§>(w,t) | 0§(x) < (t-At+ix))}; 

past s (w,f) = {xeS(w,t) I 6§(x)<t}; 

match = {Xj(y) = k(x)) A G 8g(x)). 

Definition 8 (Conformance relation) The implementation behavior J is said to be conforming to the 
specification behavior § iffdom3 = domS and for all w G domS and t G T, there is a relation M(w,f) C 
{(x,y) G pastg(w,?) x pastj(w,?) | match(.x,;y)} (called a matching relation), such that: 

1. M,(w,t) is a one-to-one relation; 

2. for each x G past^(w,f), there is y G pastj(w,f), such that (x,y) G M(w,f); 

3. for each y G pastj' (w,t), there is x G past§(w,f), such that (x,y) G M(w,f); 

4. for all (x,y),(x/,y') G M(w,t), if x -< x 1 , then dj(y) < dj(y'). 

If for some w G I a«<i ? G T the abovementioned properties are violated, then 3 is said to be not conforming 
to §, and wjo.f] is referred to as a counterexample. □ 

Figure [3] illustrates the conformance relation definition for a particular input sequence (being unim- 
portant it is not shown in the picture) and observation time (t = 4). The upper part of the figure is a 
drawing of the implementation outputs (black circles with white labels: b, a and c). The lower part 
depicts the specification outputs (white circles with black labels: a, b, c and d). Let us denote the trace 
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vertices (i.e., circles themselves) by y^, y a and y c (for the implementation) and x a , Xb, x c and Xd (for 
the specification). The implementation vertices are not causally related to each other, while the spec- 
ification vertices are partially ordered (the precedence relation is drawn by arrows: x a -< x c , -< x c , 
x a -< Xd and Xj, -< Xd) and are tagged with time intervals (8(x a ) = [0,2], S(xb) = [1,3], 5(x c ) = [0,4] and 
S(xd) = [1,5]). Matchings are depicted by intermittent lines connecting the implementation vertices with 
the specification ones ((x a ,y a ), (xb,yb) and (x c ,y c )). It is easy to see that this relation fits the matching 
relation definition: (1) it is one-to-one relation; (2 & 3) it includes all events whose lifetime has been 
exhausted; (4) is preserves the specification ordering: 



• 


(xa <x c ) and (d(y a ) 


= 2 < 3 = 






• 


(x b -<x c ) and (6(y b ) 


= 1 <3 = 


o<yc)). 




And, 


certainly, this relation 


satisfies the matching condition: 


• 


(X(xa) =A(y a ) =a) 


and (d(y a , 


1=2 €[0,2] 


= 8(x a )); 


• 


(X(xb) = A(yj) =b) 


and [9(y b ] 


1 = 1 €[1,3] 


= 8(x h )); 


• 


[X(x c ) =X(y c ) =c) 


and (0{y c ) 


1 = 3 G [0,4] 


= 8(x c )). 



The next section describes a procedure that automatically and dynamically constructs a matching 
relation between implementation and specification outputs. If it fails to create such a relation, it reports 
the reason, which can interpreted as a failure type: a missing or unexpected implementation output. 

3.2 On-the-Fly Trace Matching 

A monitor that matches implementation and specification traces and checks their conformance is co- 
executed with the implementation and specification and reacts on their outputs. Formally, the monitor 
can be expressed as a timed automaton 13 with two types of input ports: (1) ports for receiving specifi- 
cation outputs and (2) ports for receiving implementation outputs. When the automaton detects inconsis- 
tency between implementation and specification traces, it goes into a dedicated state informing that the 
implementation is not conforming to the specification. 

A formal description of the on-the-fly trace matcher is given below. It is represented as a system of 
guarded actions. Each action is atomic and is executed as soon as the guard is true. The actions and 
their guards depend on an external variable t reflecting the current simulation time and outputs produced 
by the specification and implementation in response to the same input sequence (5 and /, respectively). 
The value of t is monotonically increasing in real time (simulation time may coincide with real time). 
The writing y € I[t] means that at time t the implementation omits an output y. The description is based 
on two functions: (1) the primary arbiter {arbiters) and (2) the secondary arbiter (arbiteri), which are 
defined as follows: 



arbiter s{X) 




ifX/0, 
otherwise (</> ^ E); 



arbiter j(y,X) 




if there is x G X, such that match(x,y) 
otherwise. 
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Action 1 onSpecOutput[x\, x G S[f] 


Action 2 onImplOutput[y], y G 


Guard: frwe 


Guard: frwe 


Input: x 


Input: j 


pasts <= pasts U {■*} 


^asfy U {y} 


if x G arbiters(pasts) then 


x arbiterj(y,arbiters(pasts)) 


for all j G /^asfy [in ascending of 6j(y)] do 


ifx^(j> then 


if x = arbiter[(y,{x}) then 


pasts pasts \ { x } 


pasts <= pasts \ {*} 


past j <= past/ \ {y} 


pasti <= pastj \ {y} 


match 4= matchL) {(x,y)} 


match <= match U { (x, y) } 


trace((x,j), "Conforming output") 


trace((x,y), "Conforming output") 


end if 


break 




end if 




end for 




end if 






Action 3 onSpecTimeout[x], x G /ja^s 


Action 4 onImplTimeout\y], y G pasti 


Guard: (0 s (jc) + At + (x)) <t 


Guard: (Oo(y) + At~(y)) <t 


Input: x 


Input: y 


pasts pasts \ { x } 


pasti <= pastj \ {y} 


verdict false' 


verdict <= false 


trace((x,0), "Missing output") 


trace((0,j), "Unexpected output") 


terminate 


terminate 




Action 5 onlnitialize 


Action 6 onFinalize 


Guard: t = 


Guard: (end(S) + AT+) < t A (end(7) +AT~) < t 


Input: 


Input: 


pasts <= 


verdict true 


pastj 


terminate 


match 





Given a time point, the timeout actions (onSpecTimeout and onlmplTimeout), if they are activated, 
are called after the output reception actions (onSpecOutput and onlmplOutput). Otherwise, there might 
be a false negative. E.g., when the implementation sends an output y at time t and there is x G pasts, 
such that Ag(x) = hjiy) and (6§(x) + At + (x)) = t (thus, Bj(y) is a boundary point of d§(x)), calling 
onSpecTimeout before onlmplOutput would lead to the undesirable failure. If there are two specifi- 
cation outputs x and x', such that 6§(x) = 6s(x') and x -< x', calling onSpecOut put[x] should precede 
calling onSpecOutput[x'}. The initialization action (onlnitialize) comes first, while the finalization ac- 
tion (onFinalize) is the last action within a time slot. The order between the timeout actions as the order 
between the output reception actions is insufficient and may be arbitrary. The sequence for checking 
guards and activating actions within a time slot t is as follows: 

1. initialization (onlnitialize); 

2. output reception (onSpecOutput [x] and onlmplOut put[y], x G S[t] and y G I[t]); 
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3. timeouts (onSpecTimeout [x] and onlm plTimeout [_>'] , x G £>asfs and j G pastj); 

4. finalization (onFinalize). 

Note that when we say that some property cp holds at time t, we mean that (p holds after all of the actions 
activated at time t have completed. For a multi-port system, the monitor can be decomposed into a 
number of loosely connected sub-monitors serving individual ports. If the specification abstracts away 
from the inter-port dependencies, the sub-monitors are fully independent and can work in parallel. 

Statement 1 (Monitor correctness) An input sequence w is a counterexample for J being conforming 
to § iff the monitor terminates with verdict = false. O 

Rigorously speaking, the termination condition (end(7) + AJ~) < t cannot be checked for "black- 
box" implementations (a monitor is not able to identify whether the implementation is quiescent or ac- 
tive). However, for some types of systems (in particular, systems with covergent behavior) the condition 
can be approximated with a checkable one. 

Definition 9 (Convergent behavior) The behavior S:IxT->0« called convergent iff the following 
conditions are met: 

- for every finite w G I, there exists T(w) G T, called the stabilization time, such that for any t > 
T(w), e B(w,t) = , B(w,T(w)) CB{w) denotes S(w,T(w))j; 

- for every t £T, 23 (£,*) = £ holds (the initial state is quiescent); 

- for every finite w,v G I, such thatv / £ and to = begin (v) > T(w), t>to and At G T, 

H{w(v + At),t + At) [to+Aut+At] = B(wv,r) M +At, 

t < begin(E(wv)[7>) )00 )), »/£(•)[•) £>' 

w/zere w + Af denotes the sequence constructed from w by adding At to each time stamp of w 
(quiescent states are stable). O 

Assuming that the implementation under verification is convergent, the termination condition may 
be expressed as follows: 

(j(w) < t) A ((end(V (w)] ) +AT~) < t) . 
3.3 Specifications with Optional Outputs 

There are systems where operations in some situations terminate other operations, conflicting with them 
and of a lower priority. For example, a write operation can be cancelled by another write operation 
targeted at the same location and started right after the previous one. Due to abstractness, a specification 
is not able to express precisely under what conditions operations are cancelled and their output is not 
sent outside. Taking into account such problems, the definition of the specification behavior should be 
extended. Assume there is an unary relation C V§ marking cancellable outputs (the complement of 
is denoted by □): if ()x, then the output is optional (it might be cancelled, but the cancellation condition 
is unknown or inexpressible in specification terms); if Ox, then the output is obligatory (it cannot be 
cancelled). Note that if some action is cancelled, then all dependent actions are cancelled either. 

Definition 10 (Conformance relation for specifications with optional outputs) The implementation be- 
havior J is said to be conforming to the specification behavior with optional outputs § iff domJ = 
domS and for all w G domS and t G T, there is a relation M(w,t) C {(x,y) G past s (w,?) x pastj(w,f) | 
match (x,y)}, such that: 
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1. M(w,f) is a one-to-one relation; 

2. for each x G pastf^w,?), 

- if Ox, then there is y G pastj(vv,f), smc/i that (x,y) G M(w,f); 

- j/O-f, either there isy G pastj(w,f), swc/i f/iaf (x,y) G M(w,f), orforeachx 1 G past§(w,f), 
/fx X x', f/jen f/zere no y G pastj(w,/), smc/j (jc',y) G M(w,f). 

3. for each y G pastj (w,f), f/iere i'ji G past s (w,f), smc/i f/iaf (x,j) G M(w,f); 

4. /or a// (jt,y), (V,/) G M(w,f), i/jc -< x', then dj(y) < %(/). □ 

Checking conformance to specifications with optional outputs can be done with a few modifications 
of the monitor described above. In onSpecTimeout, it should be checked whether an event x is optional 
(the action fails only if x is obligatory). The most difficult part is to track that all events dependent 
on the cancelled one are also cancelled. Assume that there is ATd ep G T, such that for all x,x' G V§, if 
\6§(x) — 6§(x')\ > ATd e p, thenx_Lx'. To describe the monitor, let us introduce apredicate cancelleds(x) = 
(3x' G terms ■ x' <x) and a modified version of the primary arbiter: arbiters(X) = m\n^(X\terms). 



Action 7 onSpecOutput[x], x G S[t] Action 8 onSpecTimeout[x], x G (pasts\terms) 

Guard: true Guard: (6§(x) + At + (x)) < t 

Input: x Input: x 
pasts <= pasts U {x} if Ux then 

if cancelled(x) then 

terms terms U {x} else 
else terms •£= terms U { x } 

end if 

end if 



Action 9 onTermTimeout[x], x G term s Action 10 onlnitialize 

Guard: (d s (x) + AT dep ) < t Guard: t = 

Input: x Input: 

pasts <= pasts \ { x } terms <^ 

terms terms \ {x} 



4 Tool Support and Experience 

The proposed approach to runtime verification has been implemented in a C++ library named C++TESK 
Testing ToolKit (U. The library provides users with classes and macros for automated development of 
test system components, including reference models, monitors (test oracles), stimuli generators, coverage 
trackers, etc. C++TESK supports testing and monitoring of both hardware and software systems but has 
been mainly used for hardware designs (namely, for simulation-based verification of microprocessor 
units). Note that hardware is usually developed in hardware description languages (HDLs), like Verilog 
and VHDL, and can be executed (simulated) in a special environment, called HDL simulator. The 
C++TESK facilities for developing reference models of hardware designs (and, consequently, runtime 
monitors) include means for sending and receiving data packages, forking and joining concurrent threads, 
modeling time delays and specifying order between data packages. Some of the primitives (the most 
important within the scope of the paper) are as follows (the syntax here differs from the original one, 
used in the toolkit): 
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• delay (n) — models a time delay (as an observable outcome, it increments the current time value 
by n time units); 

• recv (in) : pkg — waits until an input package is received at a given input port (in); then, returns 
that package (pkg); 

• send (out , pkg, opt) — sends an output package (pkg) via a given output port (out) specify- 
ing whether the package is obligatory or optional (opt); 

(Note that every time a package is sent outside, it is tagged with time interval [t — At~ ,t + A? + ], 
where t is the sending start time and At ± are user-defined parameters of the transmission port.) 

• depends (pkgl , pkg2) — states that an output package (pkgl) depends on or causally related to 
some other package (pkg2), input or output. 

(This probably answers the question raised in the beginning of Section 3 of where a specification 
trace, namely partial ordering of its events, is taken from.) 

Differences in hardware complexity, verification purposes and amounts of resources lead to the vari- 
ety of model types and model abstraction levels. Abstraction is a well-known way for fighting complexity 
and facilitating model development. Though the verification quality is likely to be lower in case of sim- 
pler reference models, if there is a strict deadline (and it is often so), there is no other way out. Event 
ordering and timing are the main subjects for abstraction in hardware designs and other concurrent time- 
dependent systems. We use the following classification of the reference models according to the time 
modeling accuracy: (1) untimed models (represent only general information on the cause-effect relation 
of their inputs and outputs, while the timing is not modelled at all: A? 1 * 1 = <»), (2) time -approximate mod- 
els (contain the detailed specification of the event ordering, including some internal arbitration schemes, 
but the timing is approximate: At < T, where T has a value of several tens of time units) and (3) time- 
accurate models (implement the exact, or almost exact, event ordering and timing: A? ± < 1). 

The proposed methodology has been used for verification of a number of units of different industrial 
microprocessors. Our experience was originally presented in O, and since then we have verified a table 
lookup unit, an 12-cache bank controller and an instruction buffer. Also, testbenches and monitors for 
several previously tested components (a north bridge data switch and a memory access unit) required 
improvement according to the modifications of the units. The newest information of the approach ap- 
plication is shown in Table [T] As it can be seen from the table, the methodology supports runtime 
verification by means of abstract models (being available at early design stages) and, at the same time, 
by means of up to time-accurate models (being available typically at finishing design stages). Moreover, 
the approach allows reusing reference models across the hardware development cycle, which is really 
important in the industrial settings. 

The first version of C++TESK supported only accurate reference models (it was required that a 
model knows the exact ordering of events on each of the output ports). Having received feedback from 
C++TESK users (everyone is welcome to join the community), the toolkit has been modified. Mostly, 
it concerns a problem of lack of unit-level specifications even for almost finished hardware designs. 
It is impossible to create an accurate model without detailed knowledge of the unit functionality and 
timing. Regular interviewing of engineers takes a lot of time and is inconvenient. Two major solutions 
of the problem have been proposed besides forcing the developers to write the specifications. The first 
solution is to reuse parts of a more complicated system-level model (emulating behavior of the whole 
microprocessor). Though such parts are rather abstract (as a rule, system-level models are developed in 
an untimed manner), they are really useful for early-stage verification. The second solution is to develop 
approximate reference models by means of C++TESK and to refine them if necessary. 
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Microprocessor Unit 


Development Stage 


Model Abstraction Level 


From 


To 


Translation lookaside buffer 


Late / finishing 


Time-approximate model 


Time-accurate model 


Floating point unit 


Late / finishing 


Untimed model 


- 


Non-blocking L2-cache 


Middle / late 


Time-approximate model 




North bridge data switch 


Middle / late / finishing 


Time-approximate model 


Time-accurate model 


Memory access unit 


Early / middle 


Untimed model 


Time-accurate model 


System interrupt controller 


Early / middle 


Untimed model 


Time-approximate model 


Table lookup unit 


Late 


Time-approximate model 




L2-cache bank controller 


Late 


Time-accurate model 




Instruction buffer 


Late / finishing 


Time-accurate model 





Table 1 : Experience of the approach application 



5 Related Work 

There are several works on model-based testing and monitoring that have similarities with our approach. 
Some of them are mentioned below. 

In Q, a partial order input/output automaton (POIOA), where each transition is associated with an 
almost arbitrary ordered set of inputs and outputs, is used to represent the expected behavior. The key 
idea is to obtain two POIOAs (representing behavior of specification and implementation) and to check 
their conformance. There is a way to derive a test suite that guarantees fault detection defined by a 
POIOA-specific fault model: missing output faults, unspecified output faults, weaker precondition faults, 
stronger precondition faults and transfer faults . If the following assumptions are satisfied: an unspecified 
input is detectable, specified ordering of outputs can be observed, response time is bounded, and each 
specification transition can be modeled as a single implementation transition, then it is possible to set 
up conformance between two POIOAs. Comforming implementation accepts any input compatible with 
the specification (and may accept more) and produces outputs defined by the specification in an order 
compatible with the specification. If the POIOAs are not conforming, it is considered as wrong behavior 
of the implementation according to the fault model. The main difficulty in the approach, in our opinion, 
is to represent behavior of specification and implementation by the proposed formalism. 

In 0, the approach to passive testing based on invariants is presented. Invariants are used as a 
means of representing the most relevant expected properties of the implementation, which should be 
exhibited in response to the corresponding test sequences. Two types of invariants are of usage: (1) 
timed consequent invariants and (2) timed observational invariants. The first type is used to check that 
an event happens (within certain time bounds) after a given trace of events. The second type is used 
to check that a given sequence of events always occur (within certain time bounds) between two given 
events. The correctness of the implementation behavior is verified in two steps. The first step is to check 
the correctness of the invariants with respect to a given specification. The second step is to check the 
correctness of a trace, recorded from the implementation, with respect to the invariants. We think, that 
this approach is applicable to monitoring of complex timed systems, but it is not clear how to maintain 
the sets of invariants (which might be huge) during the system life cycle. 

The approach proposed in lfT3l allows usage of implicitly defined asynchronous finite state machines 
(AFSMs) for model-based testing of complex distributed systems. The implementation behavior is veri- 
fied only in quiescent states of the FSM model. Thus, it is required that there is a predicate identifying 
such kind of states. The testing step is done as follows. First, all outputs are collected and their partial 



80 



Runtime Verification Based on Executable Models: On-the-Fly Matching of Timed Traces 



order is determined. Then, all possible linearizations of the events are enumerated and checked. If all 
of them fail (with respect to the specification), then the implementation is not conforming to the specifi- 
cation. As checking is performed in quiescent states only, the approach is hardly applicable to runtime 
monitoring (where there may be arbitrary input sequences, and such states are rarely visited). 

6 Conclusion 

On-the-fly analysis of system behavior is an integral part of dynamic verification of software and hard- 
ware systems. A lot of formalisms have been proposed to express correctness properties for systems of 
different types, and a great number of methods have been suggested to check whether system executions 
are conforming to the specified properties. None of them is perfect, we think, but all together they cover 
a vast spectrum of verification and monitoring tasks. Among the variety of specification approaches, ex- 
ecutable models, written in high-level programming languages, have a significant niche. First of all, such 
models are rather universal and allow expressing a broad range of behavioral and structural properties. 
Besides, programming languages (especially general-purpose languages, like C and C++) are widely 
spread in the engineering community. 

Our work focuses on using executable models for runtime verification of reactive systems, including, 
in particular, time-dependent systems. The problem is not as simple as it looks at first sight. The naive 
checking that a system and its model produce the same outputs at the same time is inadequate in the 
majority of cases. The model may abstract away from many features implemented in the system under 
verification such as event ordering and accurate timing (at least it should be abstracted from the imple- 
mentation bugs). We suppose that conformance relations used for runtime verification can be configured 
in several ways: (1) by introducing an independency relation over the model events, (2) by extending 
time points of the model outputs to time intervals and, finally, (3) by marking some of the model outputs 
as being optional. 

Basing on this idea, we have developed a method for system monitoring and proved its correctness. 
The formalization is based on the theory of traces and partially ordered multisets. The method has been 
implemented in C++TESK, an open-source toolkit for hardware modeling, analysis and verification, 
and has been successfully used in about 10 projects on simulation-based verification of microprocessor 
units. Our future research is aiming at failure diagnostics, which is a deeper analysis of specification and 
implementation traces being carried out offline. The goal is to explain what in particular went wrong 
during the monitoring and give a hint to developers where the bugs are localized. 
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